IBIS Macromodel Task Group Meeting date: 19 June 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted the we have a meeting scheduled for July 3rd, and we may want to consider cancelling it if many people are away that week. He said we will decide at the next meeting on June 26th. - Michael M. noted that he had some questions related to the BCI BIRD147.6 and repeaters. He said he would like to discuss them time permitting. ------------- Review of ARs: - Randy to update the enhanced C_comp Model BIRD draft. - Done. - Michael M. to send his "Enabling [Rgnd] and [Rpower] for Input Model_type" v2 for posting. - Done. - Arpad to send his "Questions about Usage Out parameters" for posting. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 12 meeting. Mike L. moved to approve the minutes. Michael M. seconded the motion. There were no objections. ------------- New Discussion: - Arpad asked if Walter wanted to discuss item #9 on the agenda, "Walter's drawing with Vladimir's comments." Walter said this topic no longer needed to be discussed, and the item could be removed from the agenda. Enabling [Rgnd] and [Rpower] for Input Model_type (v2): - Discussion: Michael M. noted that the only change in this version was an editorial cleanup to ensure "Rgnd" was used ("Rground" had been mistakenly used in several places in v1). Curtis asked about the statement, "The C_comp subparameter is required for [Model]s using any or all of these keywords..." Curtis noted that it is already stated elsewhere in the spec. that C_comp is required for all [Model]s. Michael M. agreed and said he had restated it in this location to make it absolutely clear that you still need C_comp even if you're using Rac and Cac. Michael M. moved that the ATM recommend draft v2 be submitted to the Open Forum as a BIRD. Walter seconded. There were no objections. Arpad asked if Michael M. wanted this to go into IBIS 7.0 or a later version. Michael M. said he had no real preference. If it went into 7.0 that was fine, but it was not a burning need so it shouldn't hold up 7.0. Usage Out and Format: - Discussion: Arpad noted that during the previous meeting's discussion he thought there was consensus that the PAM4_LowerThreshold Usage Out example on (pg. 235-236) needed to be fixed. He asked if the group thought this needed a BIRD or could be handled as an editorial task. Radek said he thought the Editorial Task Group could handle it, as it's an example and simply needs to have the Value added to all three thresholds. Bob agreed. Bob moved to have Mike L. update the known issues list for IBIS 6.1 to include this fix. Curtis seconded. There were no objections. Arpad moved on to technical issues from the previous meeting's discussion of his presentation. He asked if we needed to revisit the topic of single-valued Value for Usage Out to make it clearer what the EDA tool should do. For example, should we: 1. Explicitly state that the value in the .ami file should be ignored. 2. Or perhaps the value should be used as a default if the model doesn't return a value (Arpad referred to the example he mentioned in the last meeting in which a model had not returned a value for a particular Out parameter. This model's behavior was not legal according to the current language in the spec.) Arpad said he understood how the values for Range, Steps, List, etc., might allow the EDA tool to do some sanity checking of the value returned by the model. But for the single-valued Value Format, what's the point of having a value in the .ami file at all? Radek said that the Format is required so the EDA tool knows what type of data to expect from the model. If the Format happens to be a single Value, then it is just a place holder in the .ami file. Walter noted that he agreed that it doesn't make a lot of sense to provide a Value for an Out parameter. However, he said at this point we are stuck with it and it's not really causing any trouble. Walter suggested we simply fix the example and move on. Curtis asked if Arpad wanted to simply explicitly state that the Value is ignored. This would leave it there as a place holder for the parser, and would avoid introducing any "interdependent rules" that Bob had noted we try to avoid (i.e. avoid saying "Format is required unless it's a Value for a Usage Out" parameter). Walter said the parser changes would be trivial anyway. Walter said if someone really wanted to take the time to write up a BIRD to address this question, they could do it. Arpad said he might write up a BIRD, and that he had raised the issue to see if there was consensus that we should clarify this issue. Walter said that he didn't think it was necessary. Curtis agreed with Walter. BCI BIRD147.6 and repeaters: - Discussion: Michael M. noted one editorial issue in which language in the BIRD states "...if the channel does not have automatic link training capabilities." He noted that we should probably refer to endpoint devices, not channels, as having link training capabilities. We generally refer to the channel as the passive interconnect. Michael M. noted the following sentence from the BIRD: "Channels with repeaters will require that the downstream Rx be able to control all upstream equalization." and asked the following questions: 1. How do we define the repeater interaction for BCI purposes? We may want to spell out in the form of a table what legal and required interactions there are between BCI AMI keywords and repeaters. 2. We say something about "repeaters" specifically, but that includes redrivers and retimers. Are we saying that redriver vendors have to create optimization BCI file sequences even if their actual devices don't do that? A redriver is a device that does not necessarily interact with other devices for setting up adaptive equalization. Do repeaters have to participate in BCI even if real devices wouldn't? 3. The sentence implies that the final endpoint Rx has to optimize the equalization of all the upstream channels. Are we really referring to entire link? PCIe 4.0, for example, can have two retimers in a link. So one could have three distinct channels for a PCIe 4.0 link. Are we saying the final endpoint determines the equalization for everything in the link or just the immediate upstream channel. Michael M. noted that we might need a table with statements about what is expected, required, or illegal when BCI and repeaters interact. Walter noted that repeater BCI interaction might not have been fully thought out originally. However, he noted that he thought this could all be covered in the specific protocols. We can define a protocol that says the downstream Rx optimizes everybody, or it only optimizes the previous Tx. He noted that for a retimer it's silly for an Rx to do anything other than optimize its immediate predecessor. It's really only for a redriver that it becomes a question. Walter said the hope was that when people began to implement BCI models they would bring up these issues, as Michael was. Michael M. agreed most of it could probably be handled within the protocol. However, he noted there are some implied rules about having certain keywords exist on both the Tx and Rx end or the two devices can't talk. We have some bare minimum rules for Tx and Rx requirements, and we might need to extend that to cover the repeater case. Mike L. noted that at one point Ambrish had described how it would be handled for redrivers. He had noted that it was really important that GetWaves were called in the proper order along the channel, because each device could write things into the BCI file, and the final Rx could then see all the participants in the channel. - Michael M.: Motion to adjourn. - Justin: Second. - Arpad: Thank you all for joining. AR: Michael M. to submit his "Enabling [Rgnd] and [Rpower] for Input Model_type" v2 to the Open Forum as a BIRD (done - BIRD195). AR: Arpad to send an email to the Open Forum noting that the ATM had voted to submit BIRD195. AR: Mike L. to update the IBIS 6.1 known issues list to include adding Value entries to the PAM4 thresholds Usage Out example on pg. 235-236. ------------- Next meeting: 26 June 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives